Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000001_owner-urn-ietf _Thu Aug 1 19:26:40 1996.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA23060 for urn-ietf-out; Thu, 1 Aug 1996 19:26:40 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA23055 for <[e-mail]>; Thu, 1 Aug 1996 19:26:38 -0400
Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA23200  (mail destined for [e-mail]); Thu, 1 Aug 96 19:26:36 -0400
Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa28939;
          1 Aug 96 19:25 EDT
Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM)
    id AA09843; Thu, 1 Aug 1996 19:25:10 -0400
Date: Thu, 1 Aug 1996 19:25:10 -0400
Message-Id: <[e-mail]>
From: Lewis Girod <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from Ron
    Daniel on Mon, 08 Jul 1996 12:40:16 -0600)
Subject: Re: [URN] nasty rewriting rules
Sender: [e-mail]
Precedence: bulk
Reply-To: Lewis Girod <[e-mail]>
Errors-To: [e-mail]

Hi,

This message is in response to a thread started a long time ago by
Ron, namely, what about rewrite rules?  I have this idea that the
client side of the NAPTR system that currently uses the rewrite rules
can be replaced by a two-step process which gives a better modularity
and will make the data in the system easier to deal with (as well as
making the creation of name scheme security policies much simpler.)

The idea here is to divide the problem into two halves; first, put the
URN into a canonical form in which the direction of hierarchy is
fixed.  For example, the domain name in

    http://lcs.mit.edu/girod/paper.ps

would need to be reversed so that the hierarchy goes from biggest on
the left to smallest on the right:

    http://edu.mit.lcs/girod/paper.ps

Once the URN is in canonical form, the actual resolution process can
begin.  Because the hard part of sorting out the URN has already been
done in the initial canonicalization phase, the rest of the resolution
can be done using some very simple rules.  These rules are very
constrained in comparison to the unconstrained rewrite rules; they
operate only by taking parts off the left hand side of the canonical
string, and can either copy that data verbatim or replace it with a
specific string.  However, it appears that most stuff we want to do
can be done this way.

If such a scheme can work, there are two main benefits to the new
modularity: (1) the vast majority of the data driving the resolution
process is in a simplified and standardized form, which is easier to
check and understand because there is less flexibility and because the
hard stuff is done once at the beginning, (2) the format of the name
scheme is specified at the top and deviation from this format is more
difficult because of the restrictions placed on rules below the
initial translation.

I have invented two small languages (a translation language and a rule
language) and written up a document that explains them and gives
examples of how they can be used to do everything I could think of.  I
have also provided C code that implements the interpreters for these
languages, and some pseudocode that shows how it can be used to
operate the NAPTR resolution process.  The syntax of the languages is
terse and ugly but really easy to implement and at bottom very simple.
The syntax can probably be cleaned up significantly...

In total, I think this modification requires little in the way of
modification to the server side of the existing NAPTR code, but it
does modify the client significantly.  The C code provided should be
pretty portable and has even been tested to a degree... All of this
can be found at

   http://ana-www.lcs.mit.edu/people/girod/translator.c  (~40K)

I am curious to see what you think.

* I think that this addresses a major design flaw of the original
NAPTR system.  Do you?  Are the rewrite rules a flaw or a feature?  If
they are a flaw does this address that flaw?

* Can this two-step process handle everything we want it to handle?
If not, are there modifications to the languages that will enable it
to do so?  (In general, we can increase the complexity of the
translation language as needed, but that makes it harder to implement
and inreases the probability of bugs or loops)

* It is already clear that there are some name schemes that cannot be
efficiently resolved by this new scheme and will need to be escaped
(just as some cannot be conveniently handled by NAPTR).  To what
degree is it necessary to add flexibility beyond what is required to
grandfather in existing namespaces?  How much flexiblity is needed
beyond what is provided by this system, and how much more does the
original NAPTR proposal provide?

    - Lewis Girod

         ([e-mail])